Zmena jmena indexu u primarniho klice pro IB,FB

Otázka od: Richard Kejval

12. 11. 2002 16:11

Ahoj,

u tabulky vytvarim primarni klic prikazem:

alter table Tabulka
add constraint PK_Tabulka
primary key (Sloupec);

Po tomto prikazu se vytvori index, se systemovym jmenem RDB$Primary+Cislo.
Protoze se pozdeji potrebuji v selectu pomoci planu na tento index obracet,
potreboval bych toto jmeno nejak jednoznacne urcit uz pri vytvareni.
Ted jsem v situaci, kdy nekolik ruznych instalaci stejne DB maji tento index
pojmenovany jinak a z hlediska udrzby neni zadouci, aby kazda instalace mela
napr. proceduru, ktera se na nej odkazuje jinou.

Da se s tim neco delat, nebo to nejak obejit ?
Nebo da se alespon zjistit to cislo, ktere pouziva system na pojmenovani
toho
 indexu ?

S pozdravem
ing. Richard Kejval
IC Software s.r.o
Mobil: +420602477679

Odpovedá: Martin Schayna

12. 11. 2002 17:05

----- Original Message -----
From: "Richard Kejval" <kejval.delphi@centrum.cz>
> alter table Tabulka
> add constraint PK_Tabulka
> primary key (Sloupec);
>
> Po tomto prikazu se vytvori index, se systemovym jmenem RDB$Primary+Cislo.
> Protoze se pozdeji potrebuji v selectu pomoci planu na tento index obracet,
> potreboval bych toto jmeno nejak jednoznacne urcit uz pri vytvareni.

Resili jsme to take, ale nic nas nenapadlo. Nakonec to dopadlo tak ze
si vystacime bez predavani vlastnich planu do dotazu a spis optimalizujeme
databazi a dotazy nez abychom nutili IB/FB do vlastnich planu.

Mate nejake vyznamne duvody pro vlastni plany, nebo je to jen proto
ze se se IB/FB obcas splete ve vyberu planu?

Martin Schayna
Aktis a.s.

Odpovedá: Pavol Kakacka

12. 11. 2002 17:30

> From: "Richard Kejval" <kejval.delphi@centrum.cz>
> > alter table Tabulka
> > add constraint PK_Tabulka
> > primary key (Sloupec);
> >
> > Po tomto prikazu se vytvori index, se systemovym jmenem
RDB$Primary+Cislo.
> > Protoze se pozdeji potrebuji v selectu pomoci planu na tento index
obracet,
> > potreboval bych toto jmeno nejak jednoznacne urcit uz pri vytvareni.

Riesit sa to da takzvanym "hacknutim"   systemovych DB tabuliek. Potom je
ale _oprus_ vytvarat takyto PK lebo ide cez skript a "neda" sa to vyzualne.
Ine riesenie je ale zistovat dynamicky index z primarneho kluca zo sys.
tabuliek a pouzit ten. Potom nas nazov nezaujima a nedojde ani k
uzivatelskej chybe pri zapise! (ale to len ak su dotazy generovane
dynamicky)

From: "Martin Schayna" <mschayna@aktis.cz>
> Resili jsme to take, ale nic nas nenapadlo. Nakonec to dopadlo tak ze
> si vystacime bez predavani vlastnich planu do dotazu a spis optimalizujeme
> databazi a dotazy nez abychom nutili IB/FB do vlastnich planu.

Obcas je to potreba ale cti dalej...

> Mate nejake vyznamne duvody pro vlastni plany, nebo je to jen proto
> ze se se IB/FB obcas splete ve vyberu planu?
>
> Martin Schayna

Problem nastava ak mas na tabulke viac indexov na roznych stlpcoch s
rozdielnov selektivitou a s rozdielnym poradim stlpcov v indexoch.
Vtedy ak urobis dotaz a pouzijes stlpce/fieldy ktore su v oboch indexoch
pouzije sa logicky ten s nizsou selektivitou a to je u zlozenych indexov
kamen urazu. IB/FB nezistuje nezistuje na ktorom mieste v indexu (AA|BB|CC)
je nas field. ale hlavne ze index ma nizsiu selektivitu. Preto ak pouzijem
field CC pouzije sa index (AA|BB|CC) ale ! jak je vidiet z indexu je k
nicemu.

Druhy problem nastava pri joinovanych selektoch s indexom na foreign
klucoch. Ak mas v tabulkach field rovnaky i v hlavnej i v pripojenej a na to
FK, pricom obsah tabulky nemusi byt rovnaky moze dojst bud k pouzitiu
nespravneho indexu alebo dokonca volbe NATURAL !!!

A do tretice zalezi na velkosti tabuliek. Ak je tabulka kde je par tisic
zaznamov tak je to v celku jedno i ked je tam dajme tomu 10-20 uzivatelov.
Akonahle ale u tabuliek bude desat ... sto tisic a viac zaznamov zacnu sa
diat veci  
Zacne sa menit selektivita indexov (nemusi! ale moze) a NATURAL cez 100.000
zaznaomv je viac nez natural cez 1000  

Nakoniec doplnim ze index sa pouziva i pri ORDER BY a GROUP takze dalsi
dovod preco niekedy optimalizovat PLAN je dolezite.

ALE: je otazkou jak kto na to moc ponahla, lebo podla vysledkov FB1.5 ktore
som videl je optimalizator ZNACNE vylepseny!!! :-D Je vykonnejsi (az v
nasobkoch!) v urcitych situaciach a je tam i "sorting in memory" (ktory je
vykonny pri dostatocne velkej fyzickej RAM, ma torchu problemy ak OS kesuje!
ale na vsetkom sa pracuje)


Zaverom: podla mojich skusenosti sa 99.9% dotazov da napisat bez tvrdeho
PLANu! je lepsie spravne nastavit indexy, nez pouzit PLAN. Pretoze ak jeden
krat nastavim spravne indexy, mozem pouzit akukolvek dotaz a nepotrebujem
tvrdy PLAN. Ak vsak radsej zvoli zmenu PLANU, a vykaslem sa na upravu
indexov, mozem potom optimalizovat kazdy dalsi dotaz a stratim tak cas a
zarobim si na chyby (nizky vykon) v buducnosti!

Kakacka Pavol
KasiX@atlas.cz

Odpovedá: Richard Kejval

13. 11. 2002 8:20


Ahoj,

> Zaverom: podla mojich skusenosti sa 99.9% dotazov da napisat bez tvrdeho
> PLANu! je lepsie spravne nastavit indexy, nez pouzit PLAN. Pretoze ak
jeden
> krat nastavim spravne indexy, mozem pouzit akukolvek dotaz a nepotrebujem
> tvrdy PLAN. Ak vsak radsej zvoli zmenu PLANU, a vykaslem sa na upravu
> indexov, mozem potom optimalizovat kazdy dalsi dotaz a stratim tak cas a
> zarobim si na chyby (nizky vykon) v buducnosti!

A o to 1 % prave jde. Mame v databazi radove 300 ulozenych procedur a
opravdu jenom v jednom pripade tam ten plan potrebujem vnutit, protoze
se jedna o dost slozity dotaz nad velkymi tabulkami a hratky s indexy uz
jsme v tomto pripade vzdali. Nejde to opravdu nejak obejit, pres systemove
tabulky ?

S pozdravem
ing. Richard Kejval
IC Software s.r.o
Mobil: +420602477679

Odpovedá: Pavel Cisar

13. 11. 2002 9:56

Haj hou!

On 12 Nov 2002 at 14:50, Richard Kejval wrote:

> Da se s tim neco delat, nebo to nejak obejit ? Nebo da se alespon
> zjistit to cislo, ktere pouziva system na pojmenovani toho indexu ?

Da se to zjistit ze systemovych tabulek ale je to opruz. Rovnez se daji
zmenit systemove tabulky, ale ted presne nevim co to udela pri obnove ze
zalohy.

Pokud si chvili pockate (treba zatim aplikaci jen vyrabite, ale nasazovat
ji budete az za par mesicu), tak Firebird 1.5 ma nejen vylepseny
optimalizator, ale dovoluje i explicitni pojmenovani indexu vytvorenych
automaticky v ramci definice referencni integrity.

S pozdravem
Pavel Cisar
Mobil: 724 281429
http://www.ibphoenix.cz
Vse co potrebujete pro Firebird a InterBase